My only wish is that we would support the entire js there and not a few functions, because:

1. we can't tell this is just javascript without it
2. AI won't be able to help unless it knows the whitelisted functions
3. people will always ask why X works and Y doesn't

I'd love webstudio to support the entire js in the expression editor!
With this PR I wanted to make the minimum changes necessary for my usecase.

My only wish is that we would support the entire js there and not a few functions, because:

1. we can't tell this is just javascript without it

2. AI won't be able to help unless it knows the whitelisted functions

3. people will always ask why X works and Y doesn't

That's a fair point. A random list of functions is confusing, and you're right, people will always wonder why one thing works and another doesn't.

The problem with allowing everything is the security risk, right? Stuff like fetch or accessing document could open up XSS holes, and things like while(true){} could crash the builder, if I understand it correctly.

So what if we set a clear rule for what's allowed? We could support all the standard methods on primitives (Strings, Arrays, etc.) as long as they don't mutate the original data.

That way, it feels like you're just writing JavaScript for data manipulation. Methods like .map() or .slice() would be fine, but something like .pop() or .splice() wouldn't, because they change the original array and could cause weird side effects.

My PR for split(), replace(), and toLowerCase() fits this rule. It solves a real problem for building dynamic pages. Right now, those functions do work if you paste them in from a local webstudio fork where the validation check is turned off, so the linter is already out of sync with the runtime.

What do you think? I'm happy to expand the PR to include more of these "safe" methods if you agree on this as the general rule.